CAP 33 - Part 1 - Concept Poll 2

Not open for further replies.


is a Community Leaderis a Top CAP Contributoris a Contributor to Smogon
CAP Co-Leader
As with Poll 1, be sure you read through each concept carefully and review ausma's final post in the concept submissions thread. This is again linked here.

This will be a Ranked Pairs vote (RP) (a form of voting where each candidate is ranked according to head to head matchups with each of its competitors in a directed acyclic graph), the details of which were discussed here.

This is a ranked vote: order does matter! You can upvote your favorites and downvote your least favorites. You may choose to rank as many or as few options as you like, but we encourage you to rank as many options as possible to ensure your preferences are taken into account fully.

Bold your votes and nothing else!

A typical vote might look like the following:

Most Preferred
Second Most Preferred
Third Most Preferred

Any comments that the voter has would go below the votes in non-bold text. Bold text is used to determine what the user's votes are, so none of the supplementary text should be in bold.
CAP uses automated scripts to count votes. For this reason, it is very important for all ballots to be submitted correctly. If you do not compose a legal ballot, your post will be subject to moderation.
  • The scripts count bold words in ballots, so do NOT bold anything in your ballot other than the options you are voting for.
  • Do NOT put any formatting other than bold in your post.
  • Only one option per line.
  • The spelling of options must be EXACTLY correct and must match the spelling listed below.
  • Capitalization and spaces are ignored by the vote counting scripts, but you probably should not depend on it.
Composing a proper ballot is easy. Enter BBCode Edit Mode (the A in the upper right corner). Copy/paste the options directly from the OP to your ballot as plain unbolded text. Delete and/or rearrange the options to suit your preference and the poll type. Bold your vote text using bold tags or re-enter rich text mode, highlight your vote and click B. Spelling or formatting errors may spoil your ballot, so be careful!

Please post only your votes in this thread. You are allowed to say whatever you like in relation to your vote at the bottom of your post, but please do not look to begin a discussion. Keep those comments to the PS! CAP chatroom or the CAP Discord channel.

Asking for votes for your submission or for the submissions of others is not allowed. Anyone found to have done so risks punishment at the moderation team's discretion. If you find that someone has broken this rule, please contact the CAP moderation team with your evidence and no one else. Mini-moderation of this rule is also considered a serious offense and can be punished.

IMPORTANT: When voting, use only the exact name of the concept submissions as listed below! The concept submissions are quoted below in order of submission:

Very Fast Immovable Object
Title: Very Fast Immovable Object

Description: This is a wall that has a high speed stat

Justification: When designing a wall, we typically prioritize defensive typing, defensive stats, and ability choice the most, with offensive prowess and speed being secondary considerations at best. This concept aims to explore how the general considerations for designing a wall change when said wall actually has the speed stat to change how it interacts with the offensive threats it's expected to take on.

  • How and why does the Speed stat matter for a wall.
  • When and why does outrunning an offensive threat matter?
  • Is speed only useful for letting a wall force a KO on a threat before said threat can KO it? What formes of utility / recovery are strongly speed dependent?
  • Are there any options that are open to a wall specifically because of a high speed stat that may not be open to slower walls, even accounting for ability choice?
  • What makes fast walls decide to not just invest in their offenses?
  • Does being a "Fast Wall" imply some level of offensive presence? Is offensive presence necessary to truly reap the rewards of going very fast?
No Shuckles Given
Name: No Shuckles Given

Description: This Pokemon would be built with minimal to no focus on its offensive capabilities.

Justification: CAP often prioritizes offense above all other defining features. This is so prevalent that we tend to build with one of two distinct stat chassis: fast, semi-frail offensive mon or fatter balance mon. Both chassis rely on swinging hard in conjunction with their other defining characteristics. This concept aims to abandon this safety net and explore what it means to build a mon that cannot meaningfully rely on raw offensive potential.

Questions To Be Answered:
  • What other ways can a Pokemon make progress in a match that do not rely on its own offensive potential? How does typing, ability, stats, moves, and item selection synergize with each other to make non-offensive progress?
  • This type of build historically tries to make progress by enabling more offensive teammates throughout the game. How could this type of mon make progress for itself and, potentially, create non-offensive win conditions?
  • What mons already occupy this less-offensive archetype? What roles are these mons able to fill for teams, and how can we use this to inform our design choices?
  • Even less-offensive Pokemon want the ability to click an immediate, damage-dealing move: Clefable w/ Moonblast, Ferrothorn w/ Power Whip/Gyro Ball/Body Press, or Chansey w/ Seismic Toss. Would this CAP also want an option to immediately force damage despite wanting to put minimal focus on offensive capabilities?
Identity Crisis
Name: Identity Crisis

Description: At least one of this CAP’s four major design components (Typing, Ability, Stats, Moves) lies in stark contradiction to its primary role.

Justification: Trying to maximize synergy between each stage is CAP’s modus operandi, but we rarely explore the opposite: taking two elements that clash with each other, and building from there. This concept forces us to engage with a fundamentally different design philosophy than usual, shedding light on new and interesting possibilities for Pokemon design that may have never even been considered by our project, much less pursued.

  • How often do contradictory or anti-synergistic elements manifest in Pokemon designs? Which ways are the most common, and are some ways more successful than others? If so, what’s behind this success?
  • Are some contradictions deeper or more interesting than others, and if so, which ones?
  • Do certain roles tend to prefer specific anti-synergies?
  • What are some Pokemon that embody this concept well in their respective metagames, and what can we learn from their design(s)?
  • Why might (or might not) anti-synergy be something to actively pursue in this metagame? Are there certain niches or “holes” in the metagame that can only be filled by a pokemon with contradictory elements?
  • Is anti-synergy inherently a bad thing, competitively speaking? What's the difference between working around these contradictions versus working with them? How can we be successful because of these contradictions, and not merely in spite of them?
  • How might this concept affect the way the CAP process is structured? Would we need to make any adjustments to the order of stages? How should we go about choosing our intended role?
  • How can we design a CAP with this concept in mind, such that it is still a coherent final product and not just a mess of disconnected design elements?
Once again, your options are:

Very Fast Immovable Object
No Shuckles Given
Identity Crisis

Please ensure your ballot uses the concept names listed above in bold and not the usernames of the submitters. This vote will end in 24 hours, so please do not feel rushed, and instead ensure you make an informed decision!

This poll will be open for 24 hours.


Expect nothing, deliver less
is a Pre-Contributor
Very Fast Immovable Object
No Shuckles Given
Identity Crisis
Last edited:
Not open for further replies.

Users Who Are Viewing This Thread (Users: 1, Guests: 1)